Helping Programmers to Adopt Set-Based Specifications

Set theory is a key component of formal notations such as B, Z and Alloy. Set-based specifications are short while precise enough as to start the implementation. However, according to our experience, practitioners without a mathematical background find difficulties in using them. In this paper we propose the set-based programming language {log} as an aid to teach programmers to write set-based specifications. In one hand, a large class of set-based specifications can be automatically translated into {log} programs, which can be used as prototypes; on the other hand, plain {log} programs can be used as contracts, which are closer to the implementation. This could help in a widest adoption of set-based specifications since programmers seem to be adopting contracts as a form of specification. 1 Set-Based Specifications We start by considering a simple requirement and we show three different formal specifications for it. The objective is to informally discuss different aspects of each specification in terms of abstraction level, conciseness, readability and whether programmers would like to use them or not. The ultimate goal is to see whether it is possible to think of a teaching methodology taking advantage of the best of each of the considered approaches. Consider a bank which offers savings accounts to its clients. Given a savings account anyone can deposit money in it. Say the savings accounts are identified by some account ID’s. From a mathematical perspective we can see all the savings accounts of this bank as a partial function from the set of account ID’s onto the set of their balances. This can be formalized as sa ∈ ID 7 → Z, if we consider that balances are integer numbers. Hence, if a ∈ dom sa then sa(a) is the balance of account a. sa is a partial function because in any given moment not all of the account ID’s are used in the bank. Now, a formalization for the requirement about a person depositing money in an account can be as follows: a? ∈ dom sa ∧ m? > 0 ∧ sa ′ = sa ⊕ {a? 7→ sa(a?) + m?} (Set) ∨ (a? / ∈ dom sa ∨ m? ≤ 0) ∧ sa ′ = sa where variables decorated with ’?’ are meant to be input parameters; variables decorated with a prime are meant to be the value of a state variable in the next state; a? is the account where the amount m? is intended to be deposited; and the ⊕ operator roughly updates a function [14, page 102]. Note that in this model, partial functions are sets of ordered pairs. For this reason we call it a set-based specification. From now on, the term set will include binary relations, partial and total functions, and bags (multisets). In effect, all these structures can be expressed in terms of set theory as shown for example in [14]. So a set-based specification will be any specification using sets as the main mathematical structure. An alternative model, and perhaps closer to a possible implementation, is based on lists instead of partial functions. In this case we can define sa ∈ seq(ID× Z) and the specification for depositing money becomes: ∃ s1, s2 ∈ seq(ID × Z); b ∈ Z : (List) m? > 0 ∧ sa = s1 a 〈(a?, b)〉a s2 ∧ sa ′ = s1 a 〈(a?, b + m?)〉a s2 ∨ ((a?, b) / ∈ sa ∨ m? ≤ 0) ∧ sa ′ = sa where a is is the list concatenation operator. This specification is more complex because there is no easy way of expressing the modification of a list element without having its position. As can be seen, the list-based specification is harder to understand than the set-based one. We think that the true problem is that the savings accounts of a bank are not a list but, essentially, a partial function. This is a recurring observation in software specification: many real-life entities are, essentially, sets, binary relations or partial functions (seen as sets). They are not lists, trees or hash tables. Therefore, set-based specifications should be favored over other notations if the goal is to describe the essence of the problem to be implemented. A third model could be based on design-by-contract (DBC) notations such as the Java Modeling Language (JML) [3], Spec# [2] or the Eiffel contract language [10]. In this case, programmers can give a contract directly as program annotations in terms of the variables and types used in the implementation. Assume the programmer uses some implementation of Java’s Map interface [12] to store the savings accounts. Then by declaring sa as, for instance, HashMap〈ID ,Z〉 we can give the following JML contract for the deposit operation: public normal behavior (JML) requires sa.containsKey(a?) && m? > 0 ensures sa == old(sa).put(a?, old(sa).get(a?) + m?) public exceptional behavior requires !(sa.containsKey(a?) && m? > 0)